Security Policy configuration is typically “one-way”; once the intent has been configured, it is extremely difficult, if not impossible, to query and measure the intent from what has been configured. Very often, what can be expressed often falls short of what needs to be expressed. Changes to intent are extremely difficult when intent is tightly coupled with detailed configuration. Additionally, legacy access check mechanisms outlive their usefulness as oftentimes the configured policies cannot be easily migrated. To analyze the system, all accesses must be dutifully audited and carefully reconciled with the intent as embodied in the configured security policy, requiring substantial human effort. As a result, users face the following problems:
1. No way to define access control policy centrally that can be enforced on multiple file servers distributed across an administrative domain
2. No way to define access control policy centrally for multiple applications independent of the authorization evaluation mechanism in each application
3. No uniform way to define audit data collection policy centrally for resources distributed across an administrative domain
4. No way to identify accesses that violate the defined access control policy
5. No way to automatically check for consistency between defined access control policy and the behavior of authorization evaluation mechanisms
6. No way to group resources across applications and policy stores for applying common authorization policy
7. No business-friendly user-experience (UX) for supporting delegation of rights on resources and of specifying authorization policy.
8. No easy mechanism to delegate personal permissions to other principals or mechanism to share the administrative burden between principals in a tightly constrained manner
The root of the problem is that there is no explicit preservation of policy intent separate from what's native to the access check mechanism. Policy is configured with one purpose: for the access check mechanism to consume it to dictate whether access ought to be granted. Given this, policy representation is biased towards optimizing the performance of the access check, which is undeniably important. But the price to pay has been that it is extremely hard to unearth the meaning of what has been configured. Even in a homogenous environment, such as multiple different shares with the same or similar access control list (ACL) configurations, it is not easy and often impossible to systematically discern that the same policy was applied to all of these shares, and therefore recapture the intent behind that policy. Heterogeneous environments exacerbate this problem. When policy is deeply mired in the representations native to the access check implementations, there is little chance of extracting abstract policy from what has been configured in the native control mechanisms. Since the policy intent itself is not independently persisted and managed, it is impossible to express anything richer than what the underlying access check mechanism allows. The implication is that there ends up being a wide gap between the intent and the implementation of that intent in the native policy configuration formats.
Thus, needed are processes and a system that addresses the shortcomings of the prior art.